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Abstract 

A new solution to the Generalized Railroad Crossing problem, based on timed automata, invariants 
and simulation mappings, is presented and evaluated. The solution shows formally the correspondence 
between four system descriptions: an axiomatic specification, an operational specification, a discrete 
system implementation, and a system implementation that works with a continuous gate model. 

1 Introduction 

During the last decade, a large collection of formal methods have been invented for specifying, 
designing, and analyzing real-time systems. To compare these methods and to better understand 
their use in developing practical real-time systems, one of us (Heitmeyer) has defined a benchmark 
problem, called the Generalized Railroad (GRC) Crossing [7]. The problem is as follows. 

The system to be developed operates a gate at a railroad crossing. The railroad crossing I lies 
in a region of interest R, i.e., I C R. A set of trains travel through R on multiple tracks in 
both directions. A sensor system determines when each train enters and exits region R. To 
describe the system formally, we define a gate function g(t) £ [0,90], where g(t) = means 
the gate is down and g(t) = 90 means the gate is up. We also define a set {A;} of occupancy 
intervals, where each occupancy interval is a time interval during which one or more trains 
are in I. The ith occupancy interval is represented as A; = [tj, vi\, where tj is the time of the 
ith entry of a train into the crossing when no other train is in the crossing and V{ is the first 
time since tj that no train is in the crossing (i.e., the train that entered at tj has exited as 
have any trains that entered the crossing after tj). 

Given two constants £i and £2, £1 > 0, £2 > 0, the problem is to develop a system to operate 
the crossing gate that satisfies the following two properties: 

Safety Property: t £ U;A; =>■ g(t) = (The gate is down during all occupancy intervals.) 
Utility Property: t (fi U;[t; — £1, V{ + £2] =► g(t) = 90 (The gate is up when no train is in 
the crossing.) 

To solve the GRC problem, real-time researchers have applied a variety of formal methods, 
including process algebraic [9, 3, 1], event-based [10], and logic-based approaches [19, 11]. They 
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have also used various mechanical proof systems, including PVS [18], EVES [11], and FDR [2], to 
formally analyze and verify their solutions. Reference [5] describes three early efforts to solve the 
GRC problem. 

This paper describes a new solution of the GRC based on the Lynch- Vaandrager timed automaton 
model [16, 15], using invariant and simulation mapping techniques [12, 15, 14]. To develop the 
solution, a "formal methods expert" (Lynch) and an "applications expert" (Heitmeyer) worked closely 
together to refine the GRC problem statement and to design and verify an implementation. 

Our close collaboration was in sharp contrast to the limited interaction between the Naval Re- 
search Laboratory (NRL) group that originated the GRC problem and the formal methods groups 
that developed earlier solutions. In the earlier work, the NRL group limited interaction both to en- 
courage original solutions and to prevent some groups from having more information and thus unfair 
advantage over other groups. While these early efforts produced a variety of solutions and many 
insights into the relative strengths and weaknesses of the different formalisms, they suffered from 
two limitations. First, because the original problem statement was somewhat ambiguous, each group 
solved a slightly different problem, which caused difficulties in comparing the solutions. Second, the 
limited interaction meant that deficiencies in the GRC problem statement went uncorrected. Our 
collaboration allowed us quickly to identify and correct these deficiencies. It also led us to represent 
the problem and its solution in a form that is both understandable to applications experts and usable 
by formal methods experts for verification. 

The rest of the paper is organized as follows. Section 2 describes our approach: general principles 
for applying formal methods to specify and verify real-time systems, our formal model and proof 
techniques, and an outline of how we applied the formal methods to the GRC problem. Section 3 
presents our highest-level problem specification, intended to be understood by applications experts; 
it improves over the original problem statement given above by resolving some ambiguities. Section 4 
contains a secondary operational specification, intended to be useful in formal verification. Section 5 
contains our system implementation. Section 6 contains the main correctness proof. Section 7 
describes extensions to more realistic, continuous models of the real world components. Section 8 
evaluates our solution and method. Several appendices provide background on the formal methods 
we use, plus two proofs about the high-level specification. A concise version of this report, which 
omits the details of the proofs, appears in [8]. 

2 Our Approach 

In this section, we describe our approach to solving the GRC problem. Section 2.1 contains some 
general principles for applying formal methods to real-time systems. Section 2.2 contains a descrip- 
tion of the timed automaton model and of invariant and simulation mapping proof methods. Section 
2.3 contains an overview of how we apply these formal methods to the GRC problem. 

2.1 Formal Methods for Real-Time Systems 

Applying formal methods to real-time systems involves three steps: system requirements specifica- 
tion, design of an implementation, and verification that the implementation satisfies the specification. 
This process has feedback loops. Once specified, the requirements must be revised when later steps 
expose omissions and errors. The same is true of the designed implementation. 



All three steps require close collaboration between the formal methods expert and the applications 
expert. The role of the formal methods expert is to produce formal descriptions of both the system 
requirements and the selected implementation and to prove formally that the latter satisfies the 
former. The role of the applications expert is to work closely with the formal methods expert to 
identify the "real" requirements and to ensure that the specified implementation is acceptable. In 
our collaboration, much of the dialogue focused on the system requirements. Once the requirements 
specification was acceptable, defining and verifying an implementation, while labor-intensive and 
time-consuming, was relatively straightforward. 

A system requirements specification describes all acceptable system implementations [6]. It has 
two parts: (1) A set of formal models describing the computer system at an abstract level, the 
environment (here, the trains and the gate), and the interface between them. (2) Formal statements 
of the properties that the system must satisfy. 

In developing the GRC solution, we applied the following seven software engineering principles. 
The first five concern the requirements specification. The sixth concerns the implementation and its 
verification, and the seventh is applicable to all three steps. 

1. Avoid under-specifying system requirements. The original problem statement lacked necessary 
information about the various constants. For example, the statement did not constrain the 
constant ^. A simple analysis shows that we should assume that ^ > "f c { own + £2 — e i 5 where 
e 2 is the maximum time and €1 the minimum time that a train requires to travel from entry 
into R to the crossing and "f c { own is the maximum time needed to lower the gate. 

2. Avoid over-specifying system requirements. For example, while the function g is an acceptable 
gate model, the GRC problem can be solved using a simpler, discrete model - one that repre- 
sents the gate as being in one of four states - up, going-down, down, and going-up. Our solution 
uses the simpler model, but we show in Section 7 how to extend our results to the original gate 
model. 

For another example, the Utility Property stated above does not rule out solutions in which 
the last train leaves the crossing at time t but within the interval [£, £ + £2] the gate goes first up 
and then down rapidly before the gate is raised for the second (and final) time. Such solutions, 
though not to be encouraged, should not be excluded. The essential system properties are that 
the gate must be down when a train is in the crossing and that the gate must be up during the 
specified intervals when no train is in the vicinity. During other times, we do not care what 
the gate does. 

3. Make sure the specified system behavior is reasonable. For example, suppose a train exits the 
crossing at time t and another train is scheduled to enter the crossing by time t-\-^ U p + 7 down- 
Then there is insufficient time for even one car to travel through the crossing, and thus the 
Utility Property fails to achieve its practical purpose. To rule out such useless activity, we 
modify the original problem statement to only require the gate to be raised if sufficient time, 8, 
exists for at least one car to travel through the crossing. A trivial modification of the original 
problem statement to include 8 appears in Appendix D. 

4. Specify the system requirements axiomatically rather than operationally. In the original problem 
statement, both the Safety Property and the Utility Property are expressed as axioms. Each 
axiom describes a relationship that is supposed to hold between the two components of the 



system environment, namely, the trains and the crossing gate. Thus the required system prop- 
erties are properties of the environment. Neither axiom mentions the computer system. Also, 
the two axioms are stated independently, making it easy to modify the individual properties. 

In the present study, we initially reformulated the requirements specification operationally, as 
a timed automaton. This reformulation incorporated both the Safety and Utility Properties 
into a single automaton description, thus losing the advantage of independence. Also, our 
reformulation was stronger than the original, specifying some aspects of what the computer 
system should do rather than just describing properties that the system needed to guarantee in 
the environment. Finally, the operational style of the reformulation was harder for applications 
experts to understand. Our final version of the specification, which appears in Section 3, is 
axiomatic. Like the original formulation, it describes the two properties as independent axioms 
about the environment. 

5. Provide an operational secondary specification plus a formal proof that the operational specifica- 
tion implements the axiomatic specification. Although it is desirable to start with an axiomatic 
specification, the types of proofs we do rest on operational, automaton versions of the speci- 
fication and implementation. Therefore, we present a secondary requirements specification in 
terms of timed automata and prove that the operational requirements specification implements 
the original axiomatic specification. 

As in many applications of formal methods, we initially neglected to provide a formal proof of 
the correspondence between the original specification and the reformulation within our frame- 
work. Without such a proof, there is no assurance that the properties satisfied by the system 
implementation are the ones that are really required. In our case, while it was immediately ob- 
vious that the statement of the Safety Property in our operational specification was equivalent 
to the original statement of the Safety Property, the correspondence between the two versions 
of the Utility Property was not so clear. 

6. Provide a formal model for the implementation and a proof that it implements the operational 
specification. The implementation should be described using the same model that is used for the 
operational specification, or at least one that is compatible. The proof that the implementation 
meets the specification can be done using a variety of methods. It might be done by hand, as 
in this paper, or with computer assistance. 

7. Express the system requirements specification, the implementation, and the formal proofs so 
that they are understandable to applications experts. If the requirements specification and the 
specification of the implementation are difficult to understand, the applications expert cannot 
be confident that the right requirements have been specified and that the implementation 
is acceptable. The same holds for the formal proofs: the applications expert must be able 
to understand the proofs. This gives him/her a deep understanding of how and why the 
system works and how future changes are likely to affect system behavior. To increase their 
under standability, both the formal specifications and the proofs should be based on standard 
models such as automaton models, standard notations, and standard proof techniques such as 
invariants and simulation mappings. To the extent feasible, applications experts should not be 
required to learn new notations or proof techniques. 



2.2 The Formal Framework 

The formal method we used to specify the GRC problem and to develop and verify a solution 
represents both the computer system and the system environment as timed automata, according to 
the definitions of Lynch and Vaandrager [16, 15]. A timed automaton is a very general automaton, 
i.e., a labeled transition system. It is not finite-state: for example, the state can contain real- 
valued information, such as the current time or the position of a train or crossing gate. This makes 
timed automata suitable for modeling not only computer systems but also real- world entities such as 
trains and gates. We base our work directly on an automaton model rather than on any particular 
specification language, programming language, or proof system, so that we may obtain the greatest 
flexibility in selecting specification and proof methods. The formal definition of a timed automaton 
appears in Appendix A. 

The timed automaton model supports description of systems as collections of timed automata, 
interacting by means of common actions. In our example, we define separate timed automata for the 
trains, the gate, and the computer system; the common actions are sensors reporting the arrival of 
trains and actuators controlling the raising and lowering of the gate. 

An important special case of the model, describable in a particularly simple way, is the MMT 
automaton model [17], developed by Merritt, Modugno and Tuttle. An MMT automaton consists of 
a collection of "tasks" (i.e., "processes") sharing common data, where each task has an upper bound 
and a lower bound on the time between its events. This special case is sufficient for describing several 
of our components; in particular, the trains and the discrete version of the gate. Formal definitions 
of the MMT model are given in Appendix B. Our other components, e.g., the computer system, 
cannot be expressed in the MMT style, so we describe them directly in terms of the general model. 
Instead of thinking of the MMT model as a different model, we often find it useful to regard it as 
simply a way of describing a large subclass of timed automata. 

2.3 Applying Formal Methods to GRC 

Our solution contains four system descriptions: AxSpec, the axiomatic requirements specification; 
OpSpec, the operational requirements specification; Systlmpl, the discrete system implementation; 
and Systlmpl' , a system implementation with a continuous gate model. Figure 1 illustrates the four 
specifications and how they are related. 

The top-level requirements specification, AxSpec, contains timed automata describing the com- 
puter system and its environment (the trains and gate), and axioms expressing the Safety and Utility 
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Figure 1: The four system descriptions and how they are related. In OpSpec, OpProps incorporates 
the Safety and Utility properties into the automaton that results from composing Trains, Gate, and 
CompSpec. 



Properties. The Safety Property states that any time there is a train in the crossing, the gate must 
be down. The Utility Property states that the gate is up unless there is a train in the vicinity. 
Formally, these axioms are properties added to the composition of three timed automata: Trains, 
Gate, and CompSpec, a trivial specification of the computer system interface. Figure 2 illustrates 
AxSpec. 

Next, because it is easier to use in proving correctness, we produce a secondary, more opera- 
tional requirements specification in the form of a timed automaton OpSpec. We show that OpSpec 
implements AxSpec. 

Next, we describe our computer system implementation as a timed automaton, Complmpl. Cor- 
rectness means that Complmpl, when it interacts with Trains and Gate, guarantees the Safety and 
Utility Properties. To show this, we prove that Systlmpl, the composition of Complmpl, Trains and 
Gate, provides the same view to the environment components, Trains and Gates, as the operational 
specification OpSpec. This part of the proof follows well-established, stylized invariant and simu- 
lation mapping methods, which is why we moved from the axiomatic style of specification to the 
operational style. All of these proofs can be verified using current mechanical proof technology. 

In both specification automata, AxSpec and OpSpec, and also in the implementation automaton 
Systlmpl, time information is built into the state. Timing information consists of the current time 
plus some deadline information, such as the earliest and latest times that a train that has entered R 
will actually enter the crossing. The correctness proof proceeds by first proving by induction some 
invariants about the reachable states of Systlmpl. The main work in the proof of the Safety Property 
is done by means of these invariants. An interesting feature of the proofs is that the invariants 
involve time deadline information. 

Next, we show a "simulation mapping" between the states of Systlmpl and OpSpec, again by 
induction; this is enough to prove the Utility Property. Appendix C contains formal definitions 
for simulation mappings and the correctness properties they guarantee. Like the invariants, the 
simulations involve time deadline information, in particular, they include inequalities between time 
deadlines. 

Finally, we observe that our main proofs yield a weaker result that what we really want. Namely, 
we have worked with an abstract, discrete model of the trains and gate rather than with a realistic 
model that allows continuous behavior. And we have only shown that the "admissible timed traces", 
i.e., the sequences of externally visible actions, together with their times of occurrence, are preserved, 
rather than all aspects of the environment's behavior. We conclude by showing that we have not lost 
any generality by proving the weaker results. In particular, preservation of admissible timed traces 




Figure 2: AxSpec is the composition of Trains, Gate, and CompSpec, constrained by the Safety and 
Utility properties. 



actually implies preservation of all aspects of the environment's behavior. Further, the results extend 
to Systlmpl', a system implementation with a more realistic environment model. Both extensions are 
obtained as corollaries of the results for admissible timed traces of the discrete model, using general 
results about composition of timed automata. 

3 Axiomatic Specification 

We begin with a high level axiomatic specification, AxSpec, describing the problem in terms most 
easily understood by application experts. We express the axioms solely in terms of the environment. 
We first define two timed automata, Trains and Gate, which are abstract representations of the 
trains and gate, respectively. These two components do not interact directly. We then define a 
trivial automaton CompSpec, which interacts with both Trains and Gate via actions representing 
sensors and actuators. CompSpec describes nothing more than the interface that the computer 
system must have with the environment. AxSpec is obtained by composing these three automata 
and then imposing the Safety and Utility Properties on the composition; see Figure 2. Formally, the 
two properties are restrictions on the executions of the composition. The Safety Property is just a 
restriction on the states that occur in the execution, while the Utility Property is a more complex 
temporal condition. 

3.1 Parameters and Other Notation 

We use the notation r, r' , etc. to denote (railroad) trains. We use / to denote the railroad crossing, 
R to denote the region from where a train passes a sensor until it exits the crossing, and P to denote 
the portion of R prior to the crossing. We define some positive real-valued constants: 

• €i, a lower bound on the time from when a train enters R until it reaches /. 

• €2, an upper bound on the time from when a train enters R until it reaches I. 

• 8, the minimum useful time for the gate to be up. (For example, this might represent the minimum time for a 
car to pass through the crossing safely.) 

• 7 r i own , an upper bound on the time to lower the gate completely. 

• lup, an upper bound on the time to raise the gate completely. 

• £i, an upper bound on the time from the start of lowering the gate until some train is in I. 

• {2, an upper bound on the time from when the last train leaves I until the gate is up (unless the raising is 
interrupted by another train getting "close" to I). 

• j3 , an arbitrarily small constant used to take care of some technical race conditions. 1 
We need some restrictions on the values of the various constants: 

1. ei < f2- 

2. €1 > 7 d own - (The time from when a train arrives until it reaches the crossing is sufficiently large to allow the 
gate to be lowered.) 

3. {1 > 7 r i own + ji + £2 — ei • (The time allowed between the start of lowering the gate and some train reaching I 
is sufficient to allow the gate to be lowered in time for the fastest train, and then to accommodate the slowest 
train. The time 7 r i own is needed to lower the gate in time for the fastest train, but the slowest train could take 
an additional time £2 — ei. The fi is a technicality.) 

4. {2 > lup- (The time allowed for raising the gate is sufficient.) 



These arise because the model allows more than one event to happen at the same real time. 



3.2 Trains 

We model the Trains component as an MMT automaton with no input or internal actions, and three 
types of outputs, enterR(r), enterl(r), and exit(r), for each train r. 

Actions: 



Input: 




none 




Output: 




enterR(r) 


, r a train 


enterl(r), 


r a train 


exit(r), r 


a train 


Internal: 





The state consists of a status component for each train, just saying where it is. 
State: 

for each train r: 

r. status G {not-here, P, I}, initially not-here 

The state transitions are described by specifying the "preconditions" under which each action 
can occur and the "effect" of each action. We use s to denote the state before the event occurs 
and s' the state afterwards. We use the convention that if a state component is not mentioned, it 
is unchanged (although sometimes, to resolve ambiguities or for emphasis, we say explicitly that a 
component is unchanged). 

Transitions: 

enterR(r) exit(r) 

Precondition: Precondition: 

s.r. status = not-here s.r. status = I 

Effect: Effect: 

s .r. status = P s .r. status = not-here 

enterl(r) 

Precondition: 

s.r. status = P 
Effect: 

s .r. status = I 

In this automaton (and for all the other MMT automata in this paper), we make each non-input 
action a task by itself. We only specify trivial bounds (that is, [0, oo]) for the enterR(r) and exit(r) 
actions. For each enterl(r) action, we use bounds [e l5 e 2 ]- This means that from the time when any 
train r has reached R, it is at least time €i and at most time e 2 until the train reaches /. 

We use the general construction described in Appendix B to convert this automaton to a timed 
automaton. This construction involves adding some components to the state - a current time com- 
ponent now, and first and last components for each task, giving the earliest and latest times at which 
an action of each task can occur, once the task is enabled. The transition relation is augmented with 
conditions to enforce the bound assumptions, that is, that an event cannot happen before its first 
time, and that time cannot pass beyond any last time. In this case, only the state components now, 
and first( enter I(r)) and last( enter I(r)) for each r contain nontrivial information, so we ignore the 



other cases. Applying this construction yields the timed automaton with the same actions and the 
following states and transitions. (In this automaton description, as well as elsewhere in the paper, 
we sometimes omit mention of the state where there is no ambiguity.) 

State: 

now, a nonnegative real, initially 
for each train r: 

r. status G {not-here, P, I}, initially not-here 

first(enterl(r)), a nonnegative real, initially 

last(enterl(r)), a nonnegative real or oo, initially oo. 



exit(r) 

Precondition: 

s.r. status = I 
Effect: 

s .r. status = not-here 

v(At) 

Precondition: 

for all r, s.now-\- At < s.last(enterl(r)) 
Effect: 

s .now = s.now + At 



Transitions: 

enterR(r) 

Precondition: 

s.r. status = not-here 
Effect: 

s .r. status = P 

s .first(enterl(r)) = now + ei 

s .last(enterl(r)) = now + £2 

enterl(r) 

Precondition: 

s.r. status = P 

now > s.first(enterl(r)) 
Effect: 

s .r. status = I 

s .first(enterl(r)) = 

s' .last(enterl(r)) = oo 

Lemma 3.1 In any reachable state of Trains: 

For any r such that r. status = P, first( enter I(r)) + e 2 — e i = last( enter I(r)) . 

Proof: By induction on the length, i.e., the total number of non-time-passage and time-passage 
steps, of an execution. Because e 2 — ei is a constant, we need only consider actions that change 
first( enter I(r)), last( enter I(r)) or make r. status = P, namely, enterR(r) and enterl(r). The actions 
exit(r) and z/(Ai) do not affect the statement. 

After steps, the claim is vacuously satisfied. Assume the claim is true after m steps. We must 
prove it is true after m + 1 steps. For enterl(r), the claim is vacuously satisfied. For enterR(r), the 
effect is s' .r. status = P. Then, s' .first( enter I(r)) = now-\- €i and s' .last(enterl(r)) = now-\- e 2 , which 
implies that s' .first( enter I(r)) + e 2 — e i = s' .last(enterl(r)) as required. ■ 



3.3 Gate 

We model the gate as another MMT automaton, this one with inputs lower and raise and outputs 
down and up. 

Actions: 

Input: 

lower 

raise 
Output: 



down 
up 
Internal: 



The state consists of a single status component: 



State: 

status G {up, down, going-up, going-down], initially up 

Transitions: 

lower 
Effect: 

if s. status G {up, going-up] then 

s .status = going-down 
else unchanged status 



down 

Precondition: 

s. status = going-down 
Effect: 

s .status = down 



raise 

Effect: 

if s. status E {down, going-down] then 

s' .status = going-up 
else unchanged status 



up 



Precondition: 

s. status = going-up 
Effect: 

s .status = up 



The time bounds are down: [0,7^ OU)n ], and up: [0,jup], where j U p and "f c { own are upper bounds 
on the time required for the gate to be raised and lowered. To build time into the state, the state 
components now, last(up), and last(down) are added to produce the following states and transitions. 

State: 

status G {up, down, going-up, going-down], initially up 
now, a nonnegative real, initially 
last(down), a nonnegative real or oo, initially oo 
last(up), a nonnegative real or oo, initially oo 



Transitions: 

lower 
Effect: 

if s. status G {up, going-up] then 
s' .status = going-down 
s .last(down) = now + Idown 
s .last(up) = oo 
else unchanged status, last(down), last(up) 

raise 

Effect: 

if s. status E {down, going-down] then 
s .status = going-up 
s .last(up) = now + Jup 
s .last(down) = oo 
else unchanged status, last(down), last(up) 



down 

Precondition: 

s. status = going-down 
Effect: 

s .status = down 

s .last(down) = oo 

up 

Precondition: 

s. status = going-up 
Effect: 

s .status = up 

s .last(up) = oo 

u(At) 

Precondition: 

s.now-\- At < s.last(up) 
s.now-\- At < s.last(down) 

Effect: 

s .now = s.now + At 
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3.4 CompSpec 

We model the computer system interface as a trivial MMT automaton CompSpec with inputs 
enterR(r) and exit(r) for each train r, and outputs lower and raise. 

Actions: 

Input: 

enterR(r), r a train 

ea;rt(r), r a train 
Output: 

lower 

raise 
Internal: 

CompSpec receives sensor information when a train arrives in the region R and when it leaves 
the crossing /. Note that CompSpec does not have an input action enterl(r); this expresses the 
assumption that there is no sensor that informs the system when a train actually enters the crossing. 
CompSpec has just a single state. Inputs and outputs are always enabled, and cause no state change. 
There are no timing requirements. 

Transitions: 

enterR(r) lower 

Effect: Precondition: 

none true 

Effect: 
exit(r) none 

Effect: 

none raise 

Precondition: 

true 
Effect: 
none 

3.5 AxSpec 

To get the full specification, we compose the three MMT automata given above, Trains, Gate and 
CompSpec, yielding a new MMT automaton. But this is not enough: we then add constraints to 
express the correctness properties in which we are interested. Formally, these constraints are axioms 
about an admissible timed execution a of the composition automaton: 

1. Safety Property 

All the states in a satisfy the following condition: 

If Trains.r. status = I for any r, then Gate. status = down. 

2. Utility Property 

If s is a state in a with s.Gate.status ^ up, then at least one of the following conditions holds. 

(a) There exists s preceding (or equal to) s in a with s . Trains.r . status = I for some r and s .now > s.now—^2- 

(b) There exists s following (or equal to) s in a with s . Trains.r. status = I for some r and s .now < s.now+^i. 

(c) There exist two states s and s in a, with s preceding or equal to s, s following or equal to s, 
s . Trains.r. status = I for some r, s . Trains.r. status = I for some r, and s .now — s .now < fi + {2 + <*>• 
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The Safety and Utility properties are stated independently. The Safety Property is an assertion 
about all the states reached in a, saying that they ah satisfy the critical safety property. In contrast, 
the Utility Property is a temporal property with a somewhat more complicated structure, which says 
that if the gate is not up, then either there is a recent preceding state or an imminent following state 
in which a train is in I. The third condition takes care of the special case where there is both a 
recent state and an imminent state in which some train is in /; although these states are not quite 
as recent or imminent as required by the hrst two cases, there is insufficient time for a car to pass 
through the crossing. In Appendix D, we show that the above statement of the Safety and Utility 
Properties is equivalent to a trivial modification of the original problem statement. 

3.6 Implementation Requirements 

An implementation of AxSpec uses a new timed automaton, called Complmpl, with the same interface 
as CompSpec. Complmpl will be composed with the same Trains and Gate automata given above, 
yielding a new system Systlmpl. The system Systlmpl should produce executions that, when projected 
on the environment ( Trains composed with Gate), yields behavior that is also produced by the system 
specification AxSpec. More precisely, for every admissible timed execution a of Systlmpl, there 
should be a corresponding admissible timed execution a 1 of AxSpec such that a'\Trains X Gate = 
a\ Trains X Gate. That is, the two executions project identically on the Trains and Gate automata. 

4 Operational Spec 

In contrast to AxSpec, which consists of a timed automaton together with some axioms that describe 
restrictions on the automaton's executions, the secondary operational specification, OpSpec, is simply 
a timed automaton - all required properties are built into the automaton itself as restrictions on the 
state set and on the actions that are permitted to occur. As a result, OpSpec is probably harder for 
an application expert to understand than AxSpec. But it is easier to use in proofs (at least for the 
style of verification we are using). Thus we regard OpSpec as an intermediate specification rather 
than a true problem specification; we only require that OpSpec implement AxSpec, not necessarily 
vice versa, and that all implementations of interest satisfy OpSpec. 

The two types of specifications are also different in another respect: while AxSpec preserves the 
independence of the Safety and Utility Properties, OpSpec does not. When a collection of separate 
properties are specified by an automaton, the properties usually become intertwined. 

4.1 The Specification 

To obtain OpSpec, we hrst compose Trains, Gate, and CompSpec, and then incorporate the Safety 
and Utility Properties into the automaton itself. Formally, the modified automaton is obtained 
from the composition by restricting it to a subset of the state set, then adding some additional 
state components, and finally modifying the definitions of the steps to describe their dependence on 
and their effects on the new state components. Although the composition of the three component 
automata is an MMT automaton, the modified version is not - it is a timed automaton. 

First, to express the Safety Property, we restrict the states to be those states of the composition 
that satisfy the following invariant: "If Trains. r. status = I for any r, then Gate. status = down? 
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Second, the time-bound restrictions expressed by the Utility Property are encoded as restrictions 
on the steps. The strategy is similar to that used in Appendix B to encode MMT time bound 
restrictions into the steps of a timed automaton - it involves adding explicit deadline components. 
We describe the modifications in two pieces: 

1. The time from when the gate starts going down until some train enters I is bounded by ^. To 
express this restriction formally, we add to the state of the composed system a new deadline 
lasti, representing the latest time in the future that a train is guaranteed to enter I. Initially, 
this is set to oo, meaning that there is no such scheduled requirement. To add this new 
component to OpSpec, we include the following new effects in two of the actions: 
Transitions: 

lower enterl(r) 

Effect: Effect: 

if s.Gate.status £ {up, going-up\ s .lasti = oo 

and s. lasti = oo then 
s .lasti = now + £1 
else unchanged lasti 

There is also a new precondition added: the time-passage action cannot cause time to pass 
beyond lasti. This means that whenever the gate starts moving down, some train must enter 
/ within time ^ . The new effect being added to the lower action just "schedules" the arrival 
of a train in I. 

2. From when the crossing becomes empty, either the time until the gate is up is bounded by ^ 2 or 
else the time until a train is in I is bounded by ^ 2 + <*> + £i- Again, we express the condition by 
adding deadlines, only this time the situation is trickier since there are two alternative bounds 
rather than just one. We add two new components, last 2 (up) and last 2 (T), both initially oo. 
The first represents a milestone to be noted - whether or not the gate reaches the up position 
by the designated time - rather than an actual deadline. In contrast, the second represents 
a real deadline - a time by which a new train must enter /, unless the gate reached the up 
position by the milestone time last 2 (up). To add these new components to OpSpec, we include 
the following additional effects in three of the actions: 

Transitions: 



exit(r) 






up 


Effect: 






Effect: 


if s. Trains.r .status ^ 7 for all r 


#r 


then 


if now < s.last2(up) then 


s .last2(up) = now +{2 






s .last2(up) = 00 


s' .last 2 (I) = now -\- f 2 + <*> + {1 






s .Zasfe(7) = 00 


else 






else 


unchanged Zasfe(up) 






unchanged Zasfe(up) 


unchanged lasfe(7) 






unchanged lasfe(7) 

enterl(r) 
Effect: 

s .last2(up) = 00 
s Jasfe(7) = 00 



Also, as with lasti, an implicit precondition is placed on the time-passage action, saying that 
time cannot pass beyond last 2 (I). But no such limitation is imposed for time passing beyond 
last 2 (up), because this is just a milestone to be recorded, not a time-blockage. 
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4.2 Properties 

We make some simple claims about OpSpec: 

Lemma 4.1 In all reachable states of OpSpec: 

1. If Trains. r. status = I for any r, then Gate. status = down. 

2. last 2 (up) + 8 + £i = last 2 (T). 

Proof: The first property is by definition of OpSpec. The second property is proved by induction. 
We need only consider actions that affect last 2 (up) and last 2 (T), namely, up, enterl(r), and exit(r) 
for some r. 

For the action up, the only case in which the last 2 components are affected is where now < 
s.last 2 (up). In this case, the effect of up is s' .last 2 (up) = s' .last 2 (T) = oo, and the claim is satisfied. 
The effect of enterl(r) is s' .last 2 (up) = s' .last 2 (T) = oo, and thus the claim is satisfied. For exit(r), the 
only case in which the last 2 components are affected is where r's exit leaves / empty. Then the effect 
is s' .last 2 (up) = now-\-^ 2 and s'.last 2 (I) = now + £ 2 + <*> + £i 5 which implies that s' .last 2 (up) + <5 + £i = 
s' .last 2 (T), as needed. ■ 

Lemma 4.2 In all reachable states of OpSpec: 

1. now < lasti. 

2. now < last 2 (T). 

3. If lasti ^ oo then lasti < now + ^ . 

4- If last 2 (T) ^ oo then last 2 (T) < now + £2 + ^ + £i- 
5. If last 2 (up) j^ 00 then last 2 (up) < now-\-^ 2 . 

Proof: By induction. Note that the only actions that can affect the truth of 1 or 3 are time passage, 
lower and enterl actions, and only time passage and lower actions could falsify 1 or 3. Also, the only 
actions that can affect the truth of 2, 4, or 5 are time passage, exit, up and enterl actions, and only 
time passage actions and exit actions that leave / empty could falsify 2, 4 or 5. 

1. The precondition for time passage prevents s' .now from exceeding s. lasti = s'. lasti. The effect 
of lower is s' .lasti = now + £1. By definition of the constants, ^ > 0, which implies that 
s' .lasti > now. 

2. The precondition for time passage prevents s' .now from exceeding s.last 2 (T) = s' .last 2 (T). If 
r's exit leaves / empty, then an effect of exit(r) is s' .last 2 (T) = now-\- £ 2 + 8 + £i- By definition 
of the constants, £2 + <*> + £1 > 0, which implies that s'.last 2 (I) > now. 

3. If lower causes a change, then its effect is s' .lasti = now-\- £ l5 which implies s' .lasti < now-\- ^ 
as needed. For the time passage action, suppose that s' .lasti 7^ °°- Since s. lasti = s'. lasti, we 
have s. lasti J^ °°- Then by inductive hypothesis, s. lasti < s.now-\- ^. But s.now < s' .now, so 
s.now-\- £1 < s' .now + £i- Therefore, s' .lasti < s'.now+ ^ as needed. 
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4. Time passage causes time to increase, so it cannot cause the claim to be violated. For an exit(r) 
action that leaves / empty, an effect is s' .last 2 (I) = now + £2 + <*> + £1, which suffices. 

5. Similar to 4. 



4.3 Relationship Between OpSpec and AxSpec 

We show that OpSpec implements AxSpec in the following sense: 

Lemma 4.3 For any admissible timed execution a of OpSpec, there is an admissible timed execution 
a' of AxSpec such that a'\ Trainsx Gate = a\ Trainsx Gate. (This is the same as saying that a satisfies 
the two properties given explicitly for AxSpec.) 

We leave the proof of Lemma 4.3 to Appendix E. 

Note that the relationship between OpSpec and AxSpec is only one-way: there are admissible 
timed executions of AxSpec that have no executions of OpSpec yielding the same projection. Consider, 
for example, the following example. Suppose that after / becomes empty, the system does a very 
rapid raise, lower, raise. These could conceivably all happen within time £ 2 after the previous time 
there was a train in /, which would make this "waffling" behavior legal according to AxSpec. However, 
when this lower occurs, there is no following entry of a train into /, which means that this does not 
satisfy OpSpec. 

4.4 Proof Strategy 

The relationship between OpSpec and AxSpec immediately suggests a strategy for showing that 
an implementation Systlmpl, based on a particular computer system implementation Complmpl, 
satisfies AxSpec. The strategy is to show that every admissible timed execution of Systlmpl has a 
corresponding admissible timed execution of OpSpec that projects identically on the Trains and Gate 
automata. Then use Lemma 4.3. 

5 Implementation 

To describe our implementation Systlmpl, we use the same Trains and Gate automata but replace the 
CompSpec component in OpSpec and AxSpec with a new component Complmpl, a computer system 
implement ation . 

5.1 Complmpl 

Complmpl is not an MMT automaton but a timed automaton with the same interface as CompSpec. 
It keeps track of the trains in R, together with the earliest possible time that each might enter /. 
(This time could be in the past.) It also keeps track of the latest operation that it has performed on 
the gate and the current time. 
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State: 

for each train r: 

r. status £ {not-here, R}, initially not-here 

r.sched-time, a nonnegative real number or oo, initially oo 

gate-status £ {up, rforon}, initially up 

now, initially 



Transitions: 

enterR(r) 
Effect: 

s .r. status = R 

s .r.sched-time = now + t\ 

exit(r) 
Effect: 

s .r. status = not-here 
s' .r.sched-time = oo 

lower 

Precondition: 

s. gate-status = up 

3r : s. r.sched-time < now + 1 down + /3 
Effect: 

s .gate-status = down 



raise 

Precondition: 

s. gate-status = down 

flr : s. r.sched-time < now + -y U p + <*> + 1 down 
Effect: 

s .gate-status = up 

v(At) 

Precondition: 

t = s.now + At 

if s. gate-status = up then 

t < s. r.sched-time— 1 down ^ or a ^ r 
if s. gate-status = down then 

3r : s. r.sched-time < s.now + 7^p + 8 + Idown 
Effect: 

s .now = i 



Observe that the fact that Complmpl. gate-status = up does not mean that Gate. status = up but 
just that Gate. status £ {up, going-up}. A similar remark holds for Complmpl. gate-status = down. 

Note that r.sched-time keeps track of the earliest time that train r might enter /. The system 
lowers the gate if the gate is currently up (or going up) and some train might soon arrive in /. Here 
"soon" means by the time the computer system can lower the gate plus a little bit more - this is 
where we consider the technical race condition mentioned earlier. The system raises the gate if the 
gate is currently down (or going down) and no train can soon arrive in /. This time, "soon" means 
by the time the gate can be raised plus the time for a car to pass through the crossing plus the time 
for the system to lower the gate. The system allows time to pass subject to two conditions. First, if 
gate-status = up, then real time is not allowed to reach a time at which it is necessary to lower the 
gate. Second, if gate-status = down and the gate should be raised, then time cannot increase at all 
(until the gate is raised). 

5.2 The Full System Implementation, Systlmpl 

The full system implementation, Systlmpl, is just the composition of the Trains, Gate and Complmpl 
components. 

Here, we give some useful basic invariants about Systlmpl; the next two lemmas say that 
Complmpl has accurate information about the trains and gate, respectively. 

Lemma 5.1 The following are true in any reachable state of Systlmpl: 

1. Complmpl. r. status = R iff Trains. r. status £ {P,I}. 

2. If Trains. r. status = P, then Complmpl. r.sched-time = Trains. first( enter I(r)). 



16 



3. If Complmpl.r. status = R and Complmpl.r .sched-time > now, then Trains. r. status = P. 
4- If Trains. r. status = I , then Complmpl.r. sched-time < now. 
5. If Complmpl.r. sched-time j^ 00, then Trains. r. status £ {P,I}. 

Proof: By induction. 

1. The only actions that can cause a violation are actions that change the truth values of ei- 
ther Complmpl.r. status = R or Trains. r. status £ {P,I}, namely, enterR(r) and exit(r). But, 
enterR(r) makes both sides of the equivalence true, and exit(r) makes both sides false. Hence, 
the property is true. 

2. The only actions that can cause a violation are actions that make Trains. r. status = P, or 
else change Complmpl.r. sched-time or Trains. first( enter I(r)) , namely, enterR(r), exit(r), and 
enterl(r). But exit(r) and enterl(r) cause Trains. r. status ^ P, so the claim is vacuously 
satisfied. Further, the effect of enterR(r) ensures that s' .Trains. first( enter I(r)) = now+ei, and 
s' . Complmpl.r. sched-time = now+ei. Hence, s' .Trains. first( enter I(r)) = 

s' Complmpl.r. sched-time, as required. 

3. The only actions that can cause a violation are those that can make Complmpl.r. status = R, 
increase Complmpl.r. sched-time, or make Trains. r. status ^ P, namely, enterR(r), exit(r), and 
enterl(r). The effect of exit(r) is Complmpl.r. status ^ R, and thus the claim is vacuously 
satisfied. The effect of enterR(r) is Trains. r. status = P, and thus the claim is satisfied. 

Now consider enterl(r). By the precondition of enterl(r), s. Trains. r. status = P and now > 
s. Trains. first( enter I(r)). Part 2 of this lemma implies that now > s. Complmpl.r. sched-time. 
Since s. Complmpl.r. sched-time = s' .Complmpl.r. sched-time, we have 
now > s' .Complmpl.r. sched-time, and the claim is vacuously satisfied. 

4. Suppose s' .Trains. r. status = I. Then Part f implies that s' .Complmpl.r. status = R. If 
s' .Complmpl.r. sched-time > s' .now, then Part 3 implies that s' .Trains. r. status = P, a con- 
tradiction. So, s' .Complmpl.r. sched-time < s' .now as needed. 

5. The only action that could cause a violation, enterR(r), sets s' .Complmpl.r. sched-time ^ 00. 
In this case, we have s' .Complmpl.r. status = R. Then Part I implies s 1 .Trains. r. status £ {P, /} 
as needed. 



Lemma 5.2 The following are true in any reachable state of Systlmpl: 

1. Complmpl. gate-status = up if and only if Gate. status £ {up, going-up}. 

2. Complmpl. gate-status = down if and only if Gate. status £ {down, going-down} . 

Proof: By induction. 
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1. We need only consider actions that change the truth values of Complmpl. gate-status = up and 
Gate. status £ {up, going-up}, namely, lower and raise. For a lower action, 

s' .Complmpl. gate-status = down and s' .Gate. status £ {down, going-down}, which suffices. For 
a raise action, s' .Complmpl. gate-status = up and s' .Gate. status £ {up, going-up}, which again 
suffices. 

2. Follows from Part f . 



6 Correctness Proof 

The main correctness proof shows that every admissible execution of Systlmpl projects on the external 
world like some admissible execution of OpSpec. 

We first prove a collection of invariants, leading to a proof of the safety property. All of the 
invariants are proved by induction on the length of an execution. Then we give a simulation mapping 
to show the Utility Property. Technically speaking, the simulation mapping only preserves timed 
traces, not the complete view of the environment components. However, standard composition 
techniques for timed automata show that the view is also preserved. 

6.1 Invariants 

In this section, we prove the main safety invariant, namely: "If Trains. r. status = I for any r, then 
Gate. status = down." We do this with the help of two preliminary invariants. The first invariant 
says that if a train is in the region and the gate is either up or going up, then the train must still be 
far from the crossing. 

Lemma 6.1 In all the reachable states of Systlmpl, if Trains. r. status = P and 
Gate. status £ {up, going-up}, then Trains. first( enter I(r )) > now + Idown' 

Proof: By induction. Fix any particular train r. We need only consider actions that cause 
Trains. r. status to become equal to P, cause Gate. status to change to be in {up, going-up}, decrease 
Trains. first( enter I(r)) , or increase now, namely enterR(r), raise, and v. 

1. enterR(r) 

An effect is s' .Trains. first( enter I(r)) = now + £i- Since €i > Idown by an assumption on the 
constants, we have s' .Trains. first( enter I(r)) > now + 1 doww as needed. 

2. raise 

Assume that s' .Trains. r. status = P. The precondition implies that s. Complmpl. r.sched-time > 
now + j U p + 8 + 1 doww so ^ a ^ s. Complmpl. r.sched-time > now + ldown an< ^ therefore 
s' .Complmpl. r.sched-time > now + 7 down' ^ Lemma 5.1, Part 2, s' .Complmpl. r.sched-time = 
s' .Trains. first( enter I(r)). So s' .Trains. first( enter I(r)) > now + 7 doww as nee( ied. 
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v(At) 

Assume s' .Trains. r. status = P and s' .Gate. status £ {up, going-up}. Then, Lemma 5.2 implies 

that s' .Complmpl. gate-status = up, and the precondition for time passage implies that 

s' .now < s. Complmpl. r .sched-time — "I down- By Lemma 5.1, Part 2, 

s. Complmpl. r.sched-time = s. Trains. first( enter I(r)). So, s. Trains. first( enter I(r)) > s' .now + 

1 doww wri ich implies s' .Trains. first(enterl(r)) > s'.now+ Idoww as nee( ied. 



The second invariant says that if a train is nearing / and the gate is going down, then the gate is 
nearing the down position. In particular, the earliest time at which the train might enter / is strictly 
after the latest time at which the gate will be down. 

Lemma 6.2 In all reachable states of Systlmpl, if Trains. r. status = P and 
Gate. status = going-down, then Trains. first( enter I(r)) > G ate. last( down). 

Proof: Another inductive argument. Fix any particular train r. We need only consider actions that 
make Trains. r. status = P or Gate. status = going-down, decrease Trains. first( enter I(r)) or increase 
Gate.last(down) , namely, enterR(r), lower, enterl(r), raise and down. 

1. enterl(r), raise, or down. 

In each case, the claim is vacuously satisfied. 

2. enterR(r) 

Assume s' .Trains.r. status = P and s' .Gate. status = going-down. Then, Part 2 of Lemma B.l 
implies that s' .Gate.last(down) < now + 1 d own - The effect of enterR(r) is 
s' .Trains. first( enter I(r)) = now + ei- By an assumption about the constants, €i > 1 doww an< ^ 
so now + €i > now + 7 down- ^° s ' -Trains. first( enter I(r)) > s' .Gate.last(down) as needed. 

3. lower 

Suppose s' .Trains.r. status = P. We only need to consider the case where s. Gate. status £ 
{up, going-up}, since otherwise the lower doesn't change anything. By Lemma 6.1, this implies 
that s. Trains. first( enter I(r)) > now + 7 doww w ^ich implies that s' .Trains. first( enter I(r)) > 
now + 7 down' Since now + 1 down = s ' ' -GateJast^down), the needed inequality follows. 



These invariants yield the main safety result: 

Lemma 6.3 In all reachable states of Systlmpl, if Trains.r. status = I for any r, then Gate. status 
down. 

Proof: By induction again. This time, the interesting cases are enterl and raise. Fix r. 
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1. enterl(r) 

By the precondition, s. Trains. r. status = P. 

If s. Gate. status £ {up, going-up}, then Lemma 6.1 implies that s. Trains. first( enter I(r)) > now-\- 

Idoww so s - Trains. first( enter I(r)) > now. But, the precondition for enterl(r) is 

s. Trains. first( enter I(r)) < now. This means that it is impossible for this action to occur, a 

contradiction. 

If s. Gate. status = going-down, then Lemma 6.2 implies that 

s. Trains. first( enter I(r)) > s.G ate. last( down). By Lemma B.l, s. Gate. status = going-down 
implies s.Gate.last(down) > now. This implies that s. Trains. first( enter I(r)) > now, which 
again means that it is impossible for this action to occur. 

The only remaining case is s. Gate. status = down. This implies s' .Gate. status = down, which 
suffices. 

2. raise 

We need to show that the gate doesn't get raised when a train is in /. So suppose that 
s. Trains. r. status = I. The precondition of raise states that fir: s.CompImpl.r.sched-time < 
now + 7wp + 8 + 1 doww w ^ich implies that, for all r, s.CompImpl.r.sched-time > now. But 
Parts 1 and 3 of Lemma 5.1 imply that in this case, s. Trains. r. status = P, a contradiction. 



6.2 Simulation Mapping 

Now, in order to show the Utility Property, we present the simulation mapping from Systlmpl to 
OpSpec. Specifically, if s and u are states of Systlmpl and OpSpec, respectively, then we define s and 
u to be related by relation / provided that: 

1. u.now = s.now. 

2. u. Trains = s. Trains. 2 

3. u.Gate = s.Gate. 

4. u.lasti > min{s. Trains. last(enterl(r))}. 

5. Either u.last 2 (I) > min{s. Trains. last(enterl(r))}, or 
u.last 2 (up) > now + "fup an d the raise precondition holds in s, or 
u.last 2 (up) > s.Gate.last(up) and s.Gate. status = going-up. 

The first three parts of the definition are self-explanatory. The last two parts provide connections 
between the time deadlines in the specification and implementation. In the typical style for this 
approach, the connections are expressed as inequalities. The fourth condition bounds the latest time 
for some train to enter /, a bound mentioned in the specification, in terms of the actual time it could 
take in the implementation, namely, the minimum of the latest times for all the trains in P. The 
fifth condition is slightly more complicated - it bounds the time for either some train to enter / or 



"By this we mean that the entire state of the Trains automaton, including the time components, is preserved. 
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the gate to reach the up position. There are two cases for the gate reaching the up position - one in 
which the gate has not yet begun to rise and the other in which it has. 

Theorem 6.4 / is a simulation mapping from Systlmpl to OpSpec. 

Proof: We must show the three conditions in the definition of a simulation mapping. The three 
conditions are defined in Appendix C. The first condition, preservation of the now value, is immediate 
from the definition of /. The second condition is also immediate, because the unique start states of 
the two automata satisfy all the relationships in the definition of /. The interesting condition is the 
step condition. 

Suppose that s — ► Svstlmwl s '' s an< ^ s ' sa tisfy the invariants of Systlmpl, and u G f[s] satisfies 
the invariants of OpSpec. We must produce vl G f[s'] such that there is a timed execution fragment 
from u to vl having the same timed visible actions as the given step. We do this using a case analysis 
on it. 

For each non-time-passage action 7r, we first argue that it is enabled in u and then define vl to be 
the unique state that results from applying the indicated action from state v. For the time-passage 
action, we first argue that the same amount of time can pass from u, and then define vl to be the 
unique state that results from allowing that amount of time to pass. 

Then in each case, we must check that vl G f[s']; in each case, Conditions 1-3 are easy to check, 
so we need only consider Conditions 4 and 5. Condition 4 is also easy for all cases except the lower 
action, since that is the only action that can decrease last^. (The only action that can raise the 
minimum on the right-hand side of the inequality is enterl, but that sets lasti to oo.) So we omit 
mention of Condition 4 in all other cases. 

1. 7r = enterR(r). 

Enabling: Since it is enabled in s, we have s. Trains. r.statvs = not-here. Since u G f[s], we have 
v.Trains.r.statvs = not-here. This implies that it is enabled in v. 

Condition 5: The only alternative that might be falsified by it is the second, and only if 
enterR(r) falsifies the raise precondition. So suppose that v.last 2 (vp) > now + j U p and 
the raise precondition holds in s but gets falsified in s' . Then, there exists r such that 
s 1 ' .Complmpl.r .sched-time < now + j U p + 8 + 1 down' Since an effect of the action is 
s' .Complmpl.r.sched-time = now + e l5 we have €i < jup + <*> + 1 down' 

It suffices to show that v'.last 2 (I) > s' .Trains.last(enterl(r)), since that would show that the 
action makes the first alternative of Condition 5 true. We have that vl ' .last^il) = v.last 2 (I) 
and s' .Trains. last( enter I(r)) = now + e 2 - So it suffices to show that v.last 2 (I) > now -\- e 2 . 

Since v.last 2 (vp) > now+jup, and v.last 2 (T) = v.last 2 (vp>)-\-8-\-^i (this by Part 2 of Lemma 4.1), 
it is enough to show that now+j U p + 8 + ^i > now-\- e 2 , or, more simply, that 7up + ^ + ^i > e 2- 

But j U p + 8 > €i — 1 down as n °t e( i above. And we have that ^ > 1 down + e 2 — e i 5 by an 
assumption about the constants. So, j U p + 8 + ^ > e 2 as needed. 

2. 7r = enterl(r). 

Enabling: Similar to enterR(r). 

Condition 5: it makes last 2 (T) = oo and last 2 (vp) = oo, which make the condition trivially 
true. 
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3. 7r = exit(r). 

Enabling: Similar to enterR(r). 

Condition 5: 

There are three cases, based on which of the three alternatives becomes falsified. 

(a) The first alternative is falsified. 

Then, it must be that it decreases u.las^I), and that no train is in / after the step. 
We have that u'.last 2 (I) = noffi+5+^ + 6 an( i u' .last 2 (up) = now+6- If the precondition 
for raise holds after the step, then it suffices to show that u' .last 2 (up) > now-\- ~jup- That 
is, it suffices to show that 6 > lup- But this follows from an assumption about the 
constants. 

Suppose that the precondition for raise does not hold after the step. Then there is some 
r' such that s' .Complmpl.r' .sched-time < now-\- j U p + S + 1 down' (The first precondition 
of raise, gate-status = down, cannot fail after the step because of Lemma 6.3 applied 
to s.) The fact that s' .Complmpl.r' .sched-time ^ oo and Part 5 of Lemma 7.1 together 
imply that s' .Trains. r' .status £ {P,I}. However, by assumption, no trains are in / after 
the step, so it must be that s' .Trains.r 1 '.status = P. Then Lemma 5.1, Part 2, implies 
that s' .Trains. first( enter I(r')) < now + lup + <*> + 1 doww an< ^ then Lemma 3.1 implies 
that s . Trains. last( enter I(r')) < now + lup + <*> + 1 down + e 2 — e i- It suffices to show that 
u'.last 2 (I) > s' .Trains.last(enterl(r')). To show this, it suffices to show that now -\- 1^ 2 -\- 6 -\- 
£i > now+~f U p+S+"f down +e 2 -e u or, more simply, that 6+6 > lup+ldown+ e 2~ e i- But 
this follows from the inequalities 6 ^ lup an d 6 ^ 1 down + @ + e2 — €l ^ ^ down + e 2 — e i • 

(b) The second alternative is falsified. 

Then the raise precondition must be true in s. By the precondition, s. Trains.r. status = I. 
Then Lemma 5.1, Part 4, implies that s. Complmpl.r. sched-time < now. But this violates 
the raise precondition in s, which is a contradiction. 

(c) The third alternative is falsified. 

Then s. Gate. status = going-up. By the precondition, we have s. Trains.r. status = I, so by 
Lemma 6.3, we have that s. Gate. status = down, a contradiction. 

4. 7r = raise. 

Enabling: Clearly it is enabled in u, because OpSpec imposes no preconditions on its perfor- 
mance. 

Condition 5: The only alternative that can be falsified is the second. Suppose that 
u.last 2 (up) > now+ j U p. We have u' .last 2 (up) = u.last 2 (up), so u' .last 2 (up) > now-\-^ U p- But, 
s 1 .Gate.last(up) = now-\-^ U p and s' .Gate. status = going-up, which yields the third alternative. 

5. 7r = lower. 
Enabling: As for raise. 

The precondition for lower m Systlmplimplies that s.CompImpl. gate-status = up and that there 
is a particular r such that s. Complmpl.r. sched-time < now + 7 down + @- Then Lemma 5.2 
implies that s. Gate. status £ {up, going-up}. If s. Trains.r. status = I, then Lemma 6.3 is violated 
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in s. Because s.CompImpl.r.sched-time ^ oo, it cannot be that s. Trains. r. status = not-here. 
So it must be that s. Trains. r. status = P. 

Then Lemma 5.1, Part 2, implies that s.CompImpl.r.sched-time = s. Trains. first( enter I(r)), and 
Lemma 3.1 implies that s.CompImpl.r.sched-time + e 2 — e i = s - Trains. last( enter I(r)). Thus, we 
have s. Trains. last( enter I(r)) = s.CompImpl.r.sched-time + e 2 — e i 5 < now ~^~ 7 down ~^~ @ ~^~ e2 ~ 6l ' 
< now+d by an assumption about the constants. That is, now+^i > s. Trains. last( enter I(r)). 

Condition 4: By definition of lower in OpSpec, u! .lasti = now + £i- But as we showed above, 
this is at least as great as s. Trains. last( enter I(r)) = s' .Trains. last( enter I(r)). That is, u'.lasti > 
s 1 .Trains.last(enterT(r)), as needed. 

Condition 5: The only alternative that it can falsify is the third. So suppose that u.last 2 (up) > 
s.Gate.last(up) and s. Gate. status = going-up. Lemma B.l implies that s.Gate.last(up) > now, 
so u.last 2 (up) > now. Since u.last 2 (up) = u! .last 2 (up), we have u! .last 2 (up) > now. 

Then Lemma 4.1 implies that u'.last 2 (I) = u! .last 2 (up) + ^ + 8, which is in turn > now + £i- 
Since now + ^ > s. Trains. last(enterl(r)), we have u'.last 2 (I) > s. Trains. last( enter I(r)), so 
u'.last 2 (I) > s' .Trains. last( enter I(r)). This suffices for alternative 1. 

6. 7T = up. 

Enabling: Similar to enterR. 

Condition 5: Because it doesn't decrease any of the left sides of the inequalities, it cannot 
falsify alternative 1. Alternative 2 can't hold before the step, because the raise precondition 
and the up precondition are exclusive. Suppose that it falsifies alternative 3. Then u.last^iup) > 
s.Gate.last(up) and s. Gate. status = going-up. Lemma B.l implies that s.Gate.last(up) > now, 
so u.last 2 (up) > now. But then the effect of the action implies that u! .last 2 (T) = oo, which 
suffices to satisfy alternative 1. 

7. 7r = down. 

Enabling: Similar to enterR. 
Condition 5: Straightforward. 

8. 7T = v(At). 

Enabling: We must show that time At is allowed to pass in OpSpec. This amounts to showing 
that s' .now < u.lasti and s' .now < u.last 2 (T). 

To show s' .now < u.lasti, we only need to consider the case where u.lasti 7^ oo. In this case, 
Condition 4 implies that u.lasti > s - Trains. last( enter I(r)) for some r. The precondition on 
time-passage in Complmpl implies that 
s' .now < s. Trains. last( enter I(r)). So s' .now < u.lasti, as needed. 

To show that s' .now < u.last 2 (T), we only need to consider the case where u.last 2 (T) ^ 00. In 
this case, we consider the three alternatives, for s and u. If the first alternative holds, then the 
argument is as for lasti. If the second alternative holds, then the raise precondition holds in s. 
But this implies that v cannot be enabled in s, a contradiction. If the third alternative holds, 
then s' .now < s.Gate.last(up) < u.last 2 (up) < u.last 2 (T), which suffices. 
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Condition 5: The only alternative that the time-passage action might falsify is the second. But 
this means that the raise precondition holds in s, which is impossible since then v could not 
be enabled in s. 



6.3 Putting the Pieces Together 

Theorem 6.4 and Theorem C.l together imply that all admissible timed traces of Systlmpl are 
admissible timed traces of OpSpec. This is not quite what we need. However, we can obtain the 
needed correspondence between Systlmpl and OpSpec as a corollary, using general results about 
composition of timed automata: 

Corollary 6.5 For any admissible timed execution a of Systlmpl, there is an admissible timed exe- 
cution a 1 of OpSpec such that a'\ Trains X Gate = a\ Trains X Gate. 

Putting this together with Lemma 4.3, we obtain the main theorem: 

Theorem 6.6 For any admissible timed execution a of Systlmpl, there is an admissible timed exe- 
cution a' of AxSpec such that a'\ Trains X Gate = a\ Trains X Gate. 

7 Realistic Models of the Real World 

The models used above for the trains and gate are rather abstract. An applications expert might 
prefer more realistic models, giving, for instance, exact or approximate positions for the trains and 
gate. However, a formal methods expert would probably not want to include such details, because 
they would complicate the proofs. Fortunately, we can satisfy everyone. 

It is possible to define a pair of models for any real world component, one abstract and one 
more realistic. The only constraint is that the realistic model should be an "implementation" of 
the abstract model, i.e., its set of admissible timed traces should be included in that of the abstract 
model. All the difficult proofs are carried out using the abstract models, as above. Then corollaries 
are given to extend the results to the realistic models. This extension is based on general results 
about composition of timed automata. 

For example, we can define a new type of gate component, Gate , similar to the Gate defined 
above, but having a more detailed model of gate position. Gate is also a timed automaton. Fix 
any constant 7 down , < l' down < 1 down- Define 9d to be a function mapping [Q,l' down ] to [0,90]. 
Function g d is defined so that gd(0) = 90, gdil'i ) = 0, and g d is monotone nonincreasing and 
continuous. gd(t) gives the position of the gate after it has been going down for time t. Similarly, fix 
a constant j' U n, < j U p < Jup, an d define g u to be a function mapping [0,7yJ to [0,90]. Function 
g u is defined so that g u (0) = 0, g u {l'up) = 90, and g u is monotone nondecreasing and continuous. 

The actions of Gate 1 are the same as for Gate. The state is also the same, with the addition of 
one new component pos £ [0,90] to represent the gate position, initially 90: 

State: 

status in {up, down, going-up, going-down}, initially up 

pos G [0,90], initially 90 

now, a nonnegative real, initially 

last(down), a nonnegative real or oo, initially oo 
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last(up), a nonnegative real or oo, initially oo 

The transitions are as follows. The lower and raise transitions are the same as for Gate, except 
that 7j and 7™ are used in place of "f c { own and jup- The up and down transitions contains 

new preconditions stating that the correct position has been reached. The time-passage transitions 
adjust pos. 

Transitions: 

lower up 

Effect: Precondition: 

if s. status G {up, going-up} then s. status = going-up 

s .status = going-down s.pos= 90 

s Jasttdown) = now + 71 Effect: 

1 ' 'down l 

s' .last(up) = 00 s .status = up 

else unchanged status, last(down) , last(up) s Aast(up) = 00 

raise v(At) 

Effect: Precondition: 

if s. status E {down, going-down] then t= now + At 

s'. status = going-up t < s.last(down) 

s' Aast(up) = now+ y' U p t < s.last(up) 

s' .last(down) = 00 Effect: 

else unchanged status, last(down), last(up) s .now = t 

if s. status = going-up then 

down s' .pos = mnx{s.pos, g u (t-(s.last(up)-~/' up ))} 

Precondition: elseif s. status = going- down then 

s. status = going-down s' .pos = mm{s.pos, g d (t-(s.last(down)--/' down ))} 

s.pos = else unchanged pos 
Effect: 

s .status = down 
s Jast(down) = 00 

Thus, unlike the more abstract automata considered so far, Gate allows interesting state changes 
to occur in conjunction with time-passage actions. Note that Gate contains a rather arbitrary 
decision about what happens if a lower event occurs when the gate is in an intermediate position. 
It says that the gate stays still for the initial time that it would take for the gate to move down to 
its current position if it had started from position 0. Alternative modeling choices would also be 
possible. A similar remark holds for raise. 

One detail needs mentioning: we need to verify that when we apply the functions g u and g d to 
arguments in the time-passage transitions, the arguments are in fact within the specified interval. For 
example, consider the application g u {t — (s.last(up) — 7^0))}? which occurs when s. status = going-up. 
We must be sure that < t — (s.last(up) — j' U p) < "fun- The first inequality follows from the facts 
that s.last(up) < s.now-\- j' U p and s.now < t, while the second inequality follows from the fact that 
t < s.last(up). 

We relate the new gate model to the old one. See Appendix A for the notation. 

Lemma 7.1 attraces(Gate') C attraces(Gate). 

Proof: By Theorem C.l, it suffices to show the existence of a simulation mapping from Gate 1 to 
Gate. If s and u are states of Gate 1 and Gate, respectively, then we define s and u to be related by 
relation / provided that: 
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1. u. status = s. status. 

2. u.now = s.now. 

3. u.last(down) > s.last(down). 

4. u.last(up) > s.last(up). 

It is straightforward to show that / is a simulation mapping. ■ 

Now, let Systlmpl' be the composition of Trains, Gate 1 , and Complmpl, and let AxSpec be the 
composition of Trains, Gate , and CompSpec, with Safety and Utility Properties added as in AxSpec. 
Using Theorem 6.6 and general results about composition of timed automata, we obtain: 

Theorem 7.2 For any admissible timed execution a of Systlmpl' , there is an admissible timed 
execution fi' of AxSpec such that a'\ Trains X Gate = a\ Trains X Gate . 

Proof: We define two environment automata: let E be the composition of Gate and Trains, and E' 
the composition of Gate 1 and Trains. Lemma 7.1 says that attraces(Gate) C attraces(Gate). This and 
a basic substitutivity property of composition, Lemma A.l, imply that attraces(E') C attraces(E). 

Let a' be any admissible timed execution of Systlmpl' , and let S = ttrace(a'). 

Lemma A. 2 implies that a'\E' £ atexecs(E') and a'\CompImpl £ atexecs( Complmpl). Since 
attraces(E') C attraces(E), we may obtain 7 £ atexecs(E) with ttrace(j) = ttrace(a'\E') = 
ttrace(a')\E' = S\E' = S. 

Now we construct an admissible timed execution a of Systlmpl. Since S\E = ttrace(j) and 
S\CompImpl = ttrace(a' \ Complmpl) , Lemma A. 3 implies that there is an admissible timed execution 
a of Systlmpl such that a\E = 7 and a\CompImpl = a'\CompImpl. We have that ttrace(a) = 
ttrace(j) = S. 

Next, by Theorem 6.6 applied to a, we obtain an admissible timed execution (3 of AxSpec such 
that (3\E = a\E. It follows that ttrace(P) = ttrace(a) = S and that (3 satisfies the Safety and Utility 
properties. 

Now we define an admissible timed execution fi' of the system composed of E' and CompSpec. 
Since 8\E' = ttrace(a'\E') and S\CompSpec = ttrace(fi\ CompSpec) , Lemma A. 3 implies that there is 
an admissible timed execution fi' of the system composed of E' and CompSpec such that fi'\E' = a'\E' 
and fi' \ CompSpec = (3\CompSpec. Note that ttrace(fi') = S. 

We claim that fi' satisfies the required properties. First, fi' is defined to be an admissible timed 
execution of the system composed of E' and CompSpec; to see that it is an admissible timed execution 
of AxSpec it suffices to show that it satisfies the Safety and Utility properties. But this follows from 
the facts that ttrace(P') = S = ttrace(P) and that (3 satisfies the Safety and Utility properties. (These 
properties can be inferred from the timed traces.) Second, fi'\E' = a'\E' by construction. This is as 
needed. ■ 

8 Discussion 

We have applied a formal method based on timed automata, invariants, and simulation mappings 
to model and verify the Generalized Railroad Crossing example [7]. Here, we extrapolate from this 
experience and attempt to evaluate the method for use in modeling and verifying other real-time 
systems. We also describe future work. 
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• Generality. Can the method be used to describe all acceptable implementations? It seems 
so. For instance, timed automata can have an infinite number of states and both discrete and 
continuous variables. Further, they can express the maximum allowable nondeterminism, use 
symbolic parameters to represent system constants, and represent asynchronous communica- 
tion. Thus the method is significantly more general than approaches based on model-checking, 
which typically require a finite number of states and constant timing parameters. 

• Readability. Are the formal descriptions easy to understand? The environment model and 
the system implementation model are easy to understand, since it is natural to model these as 
automata. The requirements specifications do not look so natural when expressed as automata; 
an axiomatic form seems easier to understand. However, if one starts with an axiomatic 
specification, then one has to rewrite the specification as an automaton. It may be difficult 
to determine that the automaton specification is equivalent to (or implements) the axiomatic 
specification. 

• Power. Can the method be used to verify all implementations? Simulation methods (extended 
beyond what is described in this paper, to include "backward" as well as "forward" simulations) 
are theoretically complete for showing admissible timed trace inclusion. They also seem to be 
powerful in practice, although they might sometimes benefit from combination with other 
verification methods, such as model-checking, process algebra, temporal logic or partial order 
techniques. Model-checking alone is less powerful in practice, since it only checks whether a 
subfamily of solutions satisfy some specific properties. 

• Ease of Carrying out the Proof. How hard is it to construct a proof using this method? 
Can typical engineers learn to do this? 

Constructing these proofs, though not difficult, required significant work. The hardest parts 
were getting the details of the models right and finding the right invariants and simulation 
mapping. This is an art rather than an automatic procedure. The actual proofs of the invariants 
and the simulation were tedious but routine. 

Carrying out such a modeling and verification effort requires the ability to do formal proofs, 
which most engineers are not trained to do. In contrast, using model-checking, an engineer 
can check automatically whether a given "model" satisfies the properties of interest. (Model 
checkers are already being used in practice by engineers to check the correctness of certain 
implementations, e.g., of circuits.) On the other hand, the proofs developed using the method 
of this paper are amenable to mechanical proof checking. So, automated support can be 
provided to engineers attempting to develop formal proofs. 

• Information. Does the proof yield information other than just the fact that the implemen- 
tation is correct? Does it give any insight into the reasons that the implementation works? 
Yes. The invariants and simulations that require considerable effort to produce yield payoffs 
by providing very useful documentation. They express key insights about the behavior of 
the implementation. In contrast, model-checking methods yield no such byproducts, only an 
assertion that the implementation satisfies the desired properties. 

• Scalability. Does the formalism scale up to handle larger problems? We don't yet know. Just 
reasoning about this relatively simple problem was quite complex. A bigger system will mainly 
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add complexity in the form of more system components and more actions, which leads in turn 
to more invariants, more components in the simulation mapping, and more cases in the proofs. 
But, in contrast to model-checking, the blowup should not be exponential. Nonetheless, use 
of the method for larger problems should be coupled with various methods of decomposing a 
problem so one need not reason about an entire complex system at once. Additional levels of 
abstraction and use of parallel composition should help. 

• Ease of Change. How easy is it to modify the specifications and the proofs? Separating 
the system model from the environment model and splitting the environment model into the 
individual gate model and train model makes it easy to change the descriptions. Should one 
want to use a more complex train model (for example, trains move backward as well as forward), 
one can easily substitute the revised model for the original. Expressing the required properties 
axiomatically and independently makes it easier to change the requirements. 

Changes to the specifications and implementations require, of course, changes to the proofs. 
If the changes are fairly small, however, we expect most of the prior work to survive, and the 
stylized form of the proof provides useful structure for managing the modifications. Here is a 
place where mechanical aid would be most helpful - proofs could be rerun quickly to discover 
which parts need to be changed. 

Future work includes: 

1. Trying this method out on larger examples from real-time process control and timing-based 
communication. In the real-time process control area, transportation problems are especially 
interesting to us. Some new complications are expected to arise when the continuous quantities 
of interest include velocity and acceleration as well as time and position. 

2. Developing the appropriate computer assistance for carrying out and checking the proofs. We 
plan to try to use the proof systems PVS [18] and Larch [4] to check the proofs and to assess 
the utility of mechanical proof systems for such proofs. 

3. Trying to systematize the reasoning about the correspondence between the axiomatic and 
operational specifications. 
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A The Timed Automaton Model 

This section contains the formal definitions for the timed automaton model, taken from [14]. 

A.l Timed Automata 

A timed automaton A consists of a set states(A) of states, a nonempty set start(A) C states(A) of 
start states, a set acts(A) of actions, including a special time-passage action is, a set steps(A) of steps 
(transitions), and a mapping now A : states — ► R- . (R- denotes the nonnegative reals.) The actions 
are partitioned into external and internal actions, where v is considered external; the visible actions 
are the non-z/ external actions; the visible actions are partitioned into input and output actions. 
The set steps(A) is a subset of states(A) X acts(A) X states(A). We write s — ^a s ' as shorthand 
for (s,7r,s') G steps(A), and usually write s.now A in place of now A (s). We sometimes suppress the 
subscript or argument A. 

A timed automaton must satisfy five axioms: [Al] If s G start then s.now = 0. [A2] If s — ^ s' and 
-K zfz v then s.now = s' .now. [A3] If s — v —* s' then s.now < s' .now. [A4] If s — v —* s" and s" — v —* s' , then 
s — v —* s' . Axiom [Al] says that the current time is always in a start state. Axiom [A2] says that 
non-time-passage steps do not change the time; that is, they occur "instantaneously", at a single 
point in time. Axiom [A3] says that time-passage steps must cause the time to increase; this is a 
convenient technical restriction. Axiom [A4] allows repeated time-passage steps to be combined into 
one step. 

The statement of [A5] requires the preliminary definition of a trajectory , which describes re- 
strictions on the state changes that can occur during time-passage. Namely, if / is any interval of 
R- , then an I-trajectory is a function w : / — ► states, such that w(t).now = t for all t G i", and 
w (ti) -^ w (t2) f° r all ^i , ^2 G I with t x < t 2 . That is, w assigns, to each time t in interval /, a state 
having the given time t as its now component. This assignment is done in such a way that time- 
passage steps can span between any pair of states in the range of w. If w is an /-trajectory and / is 
left-closed, then define w.ftime = min(I) and w.fstate = w(w.ftime), while if / is right-closed, then 
define w.ltime = max(T) and w.lstate = w(w.ltime). If / is a closed interval, then an /-trajectory w 
is said to span from state s to state s' if w.fstate = s and w.lstate = s' . The final axiom is: [A5] If 
s — v —* s' then there exists a trajectory that spans from s to s' . Axiom [A5] is a kind of converse to 
[A4]; it says that any time-passage step can be "filled in" with states for each intervening time, in a 
"consistent" way. 

A. 2 Timed Executions and Timed Traces 

A timed execution fragment is a finite or infinite alternating sequence a = Wo7r 1 w 1 7r 2 w 2 • • •, where: 

1. Each Wj is a trajectory and each iTj is a non-time-passage action. 

2. If a is a finite sequence, then it ends with a trajectory. 

3. If Wj is not the last trajectory in a then its domain is a closed interval. If Wj is the last 
trajectory then its domain is left-closed (and either right-open or right-closed). 

4. If Wj is not the last trajectory then Wj.lstate^^ Wj + i.fstate. 
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The trajectories describe the changes of state during the time-passage steps. The last item says 
that the actions in a span between successive trajectories. A timed execution is a timed execution 
fragment for which the first state of the first trajectory, w , is a start state. In this paper, we restrict 
attention to the admissible timed executions, i.e., those in which the now values occurring in the 
states approach oo. We use the notation atexecs(A) for the set of admissible timed executions of 
timed automaton A. A state of a timed automaton is defined to be reachable if it is the final state 
of the final trajectory in some finite timed execution of the automaton. 

In order to describe the problems to be solved by timed automata, we require a definition for their 
visible behavior. We use the notion of timed traces, where the timed trace of any timed execution 
is just the sequence of visible events that occur in the timed execution, paired with their times of 
occurrence. The admissible timed traces of the timed automaton are just the timed traces that arise 
from all the admissible timed executions. We use the notation attraces(A) for the set of admissible 
timed traces of timed automaton A. Often, we express requirements to be satisfied by a timed 
automaton A as the set of admissible timed traces of another timed automaton B. Then we say 
that A implements B if attraces(A) C attraces(B). If a is any timed execution, we use the notation 
ttrace(a) to denote the timed trace of a. 

We define a function time that maps any non-time-passage event in an execution to the real time 
at which it occurs. Namely, let it be any non-time-passage event. If it occurs in state s, then define 
time(ir) = s.now. 

A. 3 Composition 

We define a simple binary parallel composition operator for timed automata. Let A and B be 
timed automata satisfying the following compatibility conditions: A and B have no output actions 
in common, and no internal action of A is an action of B, and vice versa. Then the composition of 
A and B, written as A X B, is the timed automaton defined as follows. 



• 



• 



states(A X B) = {(s A ,s B ) £ states(A) X states(B) : s A .now A = s B .now B } 
start(A X B) = start(A) X start(B); 



• acts(A X B) = acts(A) U acts(B); an action is external in Ax 5 exactly if it is external in 
either A or B, and likewise for internal actions; a visible action of A X B is an output m Ax B 
exactly if it is an output in either A or B, and is an input otherwise; 



• 



• 



(s A ,s B ) — >*axb (s' A , s' b ) exactly if 

1. s A —^a s' A if it £ acts(A), else s A = s' A , and 

2. s B — ^ B s' B if 7r G acts(B), else s B = s' B ; 

(s A ,s B ).now AxB = s A .now A . 



Then A X B is a timed automaton. If a is a timed execution of Ax B, we write a\A and a\B for the 
projections of a on A and B, respectively. For instance, a\A is defined by projecting all states in a 
on the state of A, removing actions that do not belong to A, and collapsing consecutive trajectories. 
We also use the projection notation for sequences of actions, writing, e.g., (3\A for the subsequence 
of (3 consisting of actions of A. 
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Lemma A.l (Substitutivity) Let A and B be timed automata with the same input and output ac- 
tions, and let C be a timed automaton compatible with both. If attraces(A) C attraces(B) then 
attraces(A X C) C attraces(B X C). 

Lemma A. 2 If a £ atexecs(A X B) then a\A £ atexecs(A) and a\B £ atexecs(B). 

Lemma A. 3 Suppose that a A £ atexecs(A) and a B £ atexecs(B). Suppose (3 is a sequence of 
timed visible actions of A X B such that (3\A = ttrace(a A ) and (3\B = ttrace(a B ). Then there exists 
a £ atexecs(A X B) such that a\A= a A and a\B = a B . 

Since the composition operation is associative, up to isomorphism, we may extend it to an 
arbitrary finite number of argument timed automata. 
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B MMT Automata 

B.l Automaton Definition 

MMT automata were originally defined by Merritt, Modugno and Tuttle [17]; we use a special 
case of their definition from [12, 14]. An MMT automaton is an I/O automaton [13] together 
with upper and lower bounds on time. An I/O automaton A consists of a set states(A) of states, 
a nonempty set start(A) C states(A) of start states, a set acts(A) of actions, (partitioned into 
external and internal actions; the external actions are further partitioned into input and output 
actions), a set steps(A) of steps, and a partition part(A) of the locally controlled (i.e., output and 
internal) actions into at most countably many equivalence classes. The set steps(A) is a subset of 
states(A) X acts(A) X states(A); An action it is said to be enabled in a state s provided that there 
exists a state s' such that (s,ir,s r ) £ steps(A), i.e., such that s —^a s ' ■ A set of actions is said to 
be enabled in s provided that at least one action in that set is enabled in s. It is required that 
the automaton be input- enabled, by which is meant that it is enabled in s for every state s and 
input action it. The final component, part, is sometimes called the task partition. Each class in this 
partition groups together actions that are supposed to be part of the same "task". 

An MMT automaton is obtained by augmenting an I/O automaton with certain upper and lower 
time bound information. Let A be an I/O automaton with only finitely many partition classes. For 
each class C , define lower and upper time bounds, lower(C) and upper(C), where < lower(C) < oo 
and < upper(C) < oo; that is, the lower bounds cannot be infinite and the upper bounds cannot 
be 0. 

B.2 Timed Executions and Timed Traces 

A timed execution of an MMT automaton A is defined to be an alternating sequence of the form 
s , (71"!, ti), Si, ■ ■ ■ where the 7r's are input, output or internal actions (but not time-passage actions). 
For each j, it must be that Sj ^^ Sj+i- The successive times are nondecreasing, and are required 
to satisfy the given lower and upper bound requirements. More specifically, define j to be an initial 
index for a class C provided that C is enabled in Sj, and either j = 0, or else C is not enabled in 
Sj-i, or else iTj £ C; initial indices are the points at which the bounds for C begin to be measured. 
Then for every initial index j for a class C , the following conditions must hold: 

1. (Upper bound) 

If upper j^ oo, then there exists k > j with t k < tj + upper(C) such that either ir k £ C or C is 
not enabled in s k . 

2. (Lower bound) 

There does not exist k > j with t k < tj + lower(C) and ir k £ C . 

Finally, admissibility is required: if the sequence is infinite, then the times of actions approach oo. 

Each timed execution of an MMT automaton A gives rise to a timed trace, which is just the 
subsequence of external actions and their associated times. The admissible timed traces of the MMT 
automaton A are just the timed traces that arise from all the timed executions of A. 

MMT automata can be composed in much the same way as ordinary I/O automata, using syn- 
chronization on common actions. More specifically, define two MMT automata A and B to be 
compatible according to the same definition of compatibility for timed automata. Then the com- 
position of the two automata is the MMT automaton consisting of the I/O automaton that is the 
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composition of the two component I/O automata (according to the definition of composition in [13]), 
together with the bounds arising from the components. This composition operator is substitutive 
for the admissible timed trace inclusion ordering on MMT automata. 

B.3 MMT Automata and Timed Automata 

MMT automata are not exactly a special case of timed automata. This is because the MMT model 
uses an "external" way of specifying the time bound restrictions, via the added lower and upper 
bounds. Timed automata, in contrast, build the time-bound restrictions explicitly into the time- 
passage steps. However, it 

is not hard to transform any MMT automaton A into a naturally-corresponding timed automaton 
A' . First, the state of the MMT automaton A is augmented with a now component, plus first(C) 
and last(C) components for each class of the task partition. The first(C) and last(C) components 
represent, respectively, the earliest and latest time in the future that an action in class C is allowed 
to occur. The now, first and last components all take on values that represent absolute times, not 
incremental times. The time-passage action v is also added. The first and last components get 
updated in the natural way by the various steps, according to the lower and upper bounds specified 
in the MMT automaton A. The time-passage action has explicit preconditions saying that time 
cannot pass beyond any of the last(C) values, since these represent deadlines for the various tasks. 
Restrictions are also added on actions in any class C , saying that the current time now must be at 
least equal to first(C). 

In more detail, each state of A 1 is a record consisting of a component basic, which is a state 
of A, a component now £ R- , and, for each class C of A, components first(C) and last(C), each 
in R- U {oo}. Each start state s of A' has s. basic £ start(A), and s.now = 0. Also, if C is 
enabled in s. basic, then s.first(C) = lower(C) and s.last(C) = upper(C); otherwise s.first(C) = 
and s.last(C) = oo. The actions of A' are the same as those of A, with the addition of the time- 
passage action v. Each non-time-passage action is classified as an input, output or internal action 
according to its classification in A. 

The steps are defined as follows. If it £ acts(A), then s — ^ A i s 1 exactly if all the following 
conditions hold: 

1. s.now = s' .now. 

2. s. basic — ^ A s' .basic. 

3. For each C £ part(A): 

(a) If 7r £ C then s.first(C) < s.now. 

(b) If C is enabled in both s and s' , and it £" C , then s' .first(C) = s.first(C) and s' .last(C) = 
s.last(C). 

(c) If C is enabled in s 1 and either C is not enabled in s or it £ C then s' .first(C) = s.now + 
lower(C) and s'.last(C) = s.now + upper(C). 

(d) If C is not enabled in s' then s' .first(C) = and s' .last(C) = oo. 

On the other hand, if it = v, then s' — ^ A i s exactly if all the following conditions hold: 
1. s' .now < s.now. 
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2. s .basic = s' .basic. 

3. For each C G part(A): 

(a) s.now < s' .last(C). 

(b) s.first(C) = s'.first(C) and s.last(C) = s'.last(C). 

The resulting timed automaton A' has exactly the same admissible timed traces as the MMT 
automaton A. 

Moreover, this transformation commutes with the operation of composition, up to isomorphism. 
We refer to an MMT automaton and to its transformed version interchangeably. Another way of 
looking at the preceding construction is as showing exactly how the MMT notation is used to denote 
timed automata. 

The following is a technical lemma that is useful in some of the invariant and simulation proofs. 

Lemma B.l In all reachable states of a (transformed) MMT automaton, and for all classes C , the 
following hold. 

1. now < last(C) 

2. If last(C) 7^ oo then last(C) < now + upper(C). 
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C Invariants and Simulation Mappings 

We define an invariant of a timed automaton to be any property that is true of all reachable states. 
The definition of a simulation mapping is paraphrased from [16, 15, 14]. We use the notation 
f[s], where / is a binary relation, to denote {u : (s,u) G /}. Suppose A and B are timed automata 
and I A and I B are invariants of A and B, respectively. Then a simulation mapping from A to B 
with respect to I A and I B is a relation / over states(A) and states(B) that satisfies: 

1. If u G f[s] then u.now = s.now. 

2. If s G start(A) then f[s] n start(B) ^ 0. 

3. If s ^^>^ s', s, s' £ I A , and m G /[s] fl /_b, then there exists v! G /[«'] such that there is a timed 
execution fragment from u to u' having the same timed visible actions as the given step. 

Note that it is allowed to be the time-passage action in the third item of this definition. The most 
important fact about these simulations is that they imply admissible timed trace inclusion: 

Theorem C.l If there is a simulation mapping from timed automaton A to timed automaton B, 
with respect to any invariants, then attraces(A) C attraces(B) . 
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D Correspondence Between Original Specification and AxSpec 

We show how the Utility Property in the original formulation of the GRC [7] relates to the Utility 
Property in AxSpec. In the original formulation, the Utility Property is expressed as "If t £" U;[t; — 
£,±i v i + £2], then g(t) = 90," which can be rewritten as "If g(t) ^ 90, then t £ U;[t; — £i,ZA' + £2]-" 
In the Lynch- Vaandrager model, the Utility Property can be stated as an axiom of any admissible 
timed execution a: "If s is a state in a with s. Gate. status ^ up, then s.now £ [r, — £1,^; + £2] f° r 
some i." 

In the description of AxSpec in Section 3.5, the Utility Property is expressed as 

If s is a state in a with s. Gate. status ^ up, then at least one of the following conditions holds. 

a. There exists s preceding (or equal to) sin a with s . Trains.r. status = I for some r and s .now > s.now — {2- 

b. There exists s following (or equal to) s in a with s . Trains.r. status = I for some r and s .now < s.now -\- £\. 

c. There exist two states s and s in a, with s preceding or equal to s, s following or equal to s, s . Trains.r. status = 
I for some r, s . Trains.r. status = I for some r, and s .now — s .now < {1 + {2 + <*>• 

Lemmas D.l and D.2 show that the Lynch- Vaandrager form of the original Utility Property and the 
statement of utility in AxSpec (parts a and b only) are equivalent. 

Lemma D.l If s is a state in a and s.now £ [r, — £1,^; + £2] f or some i, then (a) or (b) holds. 
Proof: There are three cases. 

1. For s.now £ [r, — £i,t 8 ], choose s' to be the last state in a such that s' .now = T;. Then, 
s' . Trains. r. status = /for some r, and s' follows (or is equal to) s in a. Further, T; — £1 < s.now, 
which implies r, < s.now + £i. This implies s' .now < s.now + £i. 

2. For s.now £ [tj,z/j], choose s' = s. Then, s' .Trains.r. status = I for some r, and s.now > 
s.now— £ 2 by assumptions on the constants. This implies s' .now > s.now— £ 2 . 

3. For s.now £ \vi,Vi + £ 2 ], choose s' to be the first state in a such that s' .now = z/,. Then, 
s' .Trains.r. status = I for some r, and s' precedes (or is equal to) s in a. Further, s.now < 
v i + £27 which implies s.now— £ 2 < Vi. This implies s.now— £ 2 < s' .now. 



Lemma D.2 If s is a state in a and (a) or (b) holds, then s.now £ [r, — £i,^- + £2] for some i. 

Proof: Assume (a). Then, s.now — £ 2 < s' .now, which implies s.now < s' .now + £ 2 . Further, 
s' .Trains.r. status = I for some r implies r, < s' .now < z/ 8 - for some i, which implies s 1 .now -\- £ 2 < 
v i + £2- This implies s.now < z/ 8 - + £ 2 as needed. By assumptions on the constants, r, — £1 < r,. This 
implies r, — £1 < s.now, since s' precedes or is equal to s. 

Assume (6). Then, s' .Trains.r. status = I for some r implies r, < s' .now < z/,. Further, s' 
follows (or equals) s in a implies s.now < s' .now. By assumptions on the constants, z/ 8 - < z/ 8 - + £ 2 . 
Hence, s.now < z/ 8 - + £ 2 as needed. Also, r, — £1 < s' '.now — £i. Then, s' .now < s.now + £j implies 
s' .now — £i < s.now. This implies r, — £1 < s.now as needed. 
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To prevent the gate from being raised and lowered uselessly, we revised the Utility Property so 
that the gate is only raised if there is sufficient time 8, 8 > 0, for at least one car to pass through 
the crossing. To express this added constraint, the original statement can be rewritten as 

H d(t) 7^ 90, then at least one of the following holds: 

1. t G L),[t, - £i, vi + £ 2 ] or 

2. t G [vi + {2, r;+i — £1] with r 8+ i — Vi < £2 + 6 + £1 for some i. 

In the Lynch- Vaandrager model, this is expressed as 

If s is is a state in a with s. Gate. status ^ up, then for some i at least one of the following holds: 

1. s. now G [r; — £1 , Vi + £2] or 

2. s.now G [vi +6,^+1 - 6] with t, + 1 - 1/, < £ 2 + $ + 6- 

We show the equivalence between the latter statement of the Utility Property and the statement of 
utility (parts a, 6, and c) in AxSpec. 

Lemma D.3 If there exists a state s in a such that for some i either condition (1) or condition (2) 
holds, then at least one of conditions (a), (b), or (c) holds. 

Proof: Lemma D.I shows that if condition (1) holds, either (a) or (b) holds. We show that condition 
(2) implies condition (c). Let s' be some state such that s' .now = z/ 8 - and s" be some state such that 
s" .now = T i+ i. Then, by definition, s' .Trains. r. status = I for some r and s" .Trains. r. status = I for 
some r. Further, s.now £ [r, — £i,z/; + £2] implies s' .now < s.now < s" .now, so s' precedes s and s" 
follows s in a. Finally, T i+ i — z/ 8 - < £ 2 + ^ + £1 implies s" .now — s' .now < ^ + £ 2 + <*>• 



Lemma D.4 If there exists a state s in a such that at least one of conditions (a), (b), or (c) holds, 
then for some i condition (1) or condition (2) holds. 

Proof: Lemma D.2 shows that if either (a) or (b) holds, then (I) holds. We show that if condition 
(c) holds, then either (I) or (2) holds. There are two cases. 

1. Suppose s occurs during the interval [r, — £i,z/; + £2] f° r some i. Clearly, (I) holds. 

2. Suppose s occurs during the interval [^+£27 T i+\ — £1] f° r some i. Then, s' .Trains. r. status = I for 
some r and s' precedes or is equal to s implies s' .now < z/,. Similarly, s" .Trains.r. status = I for 
some r and s" follows or is equal to s implies s" '.now > r J+1 . Hence, s" .now— s' .now > T i+ i — z/,. 
This together with s" .now— s' .now < £1 + £2 + ^ implies T i+ i — z/ 8 - < ^ + £ 2 + <*>• Therefore, (2) 
holds. 
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E Proof of Relationship Between OpSpec and AxSpec 

We prove Lemma 4.3. We first prove an easy property of OpSpec: 

Lemma E.l Let a be any admissible timed execution of OpSpec. Let it be any lower event occurring 
in a from a state in which Gate. status £ {going-up, up}. Then there is an enterl event <p occurring 
after it in a, with time(cp) < time(ir) + ^. 

Proof: Suppose that it occurs from state s, leading to state s'; then time(ir) = s.now = s' .now. If 
s.lasti = oo, then the effect of lower implies that s' .lasti = s'.now-\- £i. Otherwise, part 3 of Lemma 
6.2 implies that s' .lasti < s' .now + £i- Thus, in either case, s' .lasti < s'.now + ^. 

By the precondition for the time-passage action and the fact that only enterl actions can increase 
lasti, rea l time cannot pass beyond s' .lasti unless a train enters / at a time < s'. lasti < s'.now-\- £i. 
But a is an admissible execution, so time passes to oo. It follows that there must be an enterl event 
<p occurring after it in a such that time(cp) < time(ir) + £i. ■ 

Now for the proof of Lemma 4.3: 

Proof: Let a be any admissible timed execution of OpSpec. By assumption, a satisfies the Safety 
Property, i.e., the safety invariant is true in all states of a. We show that it also satisfies the Utility 
Property. 

Let s be any state occurring in a with s. Gate. status ^ up. If s. Trains. r. status = L for any r, then 
the claim is immediate. So assume that s. Trains. r. status ^ L for all r. 

Since s. Gate. status ^ up, it must be that there was a previous lower event occurring from a state in 
which Gate. status £ {going-up, up}. (Consider the possible transitions in the automaton Gate.) Let 
7r be the last lower event preceding s that occurs from a state in which Gate. status £ {going-up, up}. 
Then Gate. status ^ up in the entire interval from just after it to s. Also, time(ir) < s.now. 

By Lemma E.l, an enterl event occurs within time ^ after it. Let (f> be the first such enterl 
event. Thus, time((f>) < time(ir) + t^i < s.now-\-£i. By the Safety Property, Gate. status = down when 
(f> occurs. We consider two cases. 

1. (f> is after s. 

Then take s' to be the state just after (f>. Then s' .now = time((f>) < s.now + £ l5 and so s' 
satisfies the axiomatic Utility Property, part (b). 

2. (f> is before s. 

Since (by assumption) there is no train in / in state s, we can find a latest exit event ip following 
(f> and preceding s, which must leave / empty. When ip occurs, the last 2 variables are set, which 
ensures that either the gate reaches the up position within time ^ 2 after ip, or some train reaches 
/ within time ^2 + ^ + ^1 after ip. We consider two subcases. 

(a) s.now < time(ip) -\- £2 • 

Then take s' to be the state just prior to ip. Then s' .now = time(ip) > s.now— ^ 2 , an d so 
s' satisfies the axiomatic Utility Property, part (a). 
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(b) s.now > time(ip) + £ 2 - 

Then the gate cannot reach the up position within time ^ 2 after ip, because Gate. status ^ 
up throughout the interval from it to s. So it must be that some train reaches / within 
time ^2 + ^ + ^1 after ip. That is, there must be some enterl event ip' following ip, with 
time(ip') < time(ip) + ^ 2 + <*> + ^i- 

We claim that ip' must follow s. For if it did not, the fact that / is empty in s would 
imply that there must be an exit event following ip' and preceding s, which contradicts 
our choice of ip. Then take s' to be the state just before ip and s" to be the state just 
after ip'. Then s" .now— s' .now = time(ip') — time(ip) < ^2 + ^ + ^1- Thus, s' and s" satisfy 
the axiomatic Utility Property, part (c). 
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